This application is free; no money may be charged for its distribution other than nominal online charges or disk duplication charges.
About this Application
This application was created by AppMaker Behaviours; 98% of the code was generated automatically. AppMaker Behaviours is a set of templates added to AppMaker that vastly increases the power of AppMaker-generated applications.
This is a very simple program that can view (and extract) templates from AppMaker itself. If you open AppMaker, you'll see a list window that contains names of all the templates of a certain type. Double-clicking on an entry in the list will open up a window containing the text of that particular template. It may be edited, but saving will save a text file to disk, and will not write the changes back to the opened AppMaker application. The main point of this application is to suck out all the templates of a certain type into individual text files so that they can be edited easily. Use Rez or SARez to merge your changes back into AppMaker.
The template type is shown in an edit-text box to the right of the list; this is an OSType that corresponds to one of the AppMaker 'Lang' resources. Some of the standard AppMaker template sets include:
TmpC Procedural C (Think and MPW)
TmpP Procedural Pascal (Think and MPW)
TmC3 MPW C++ with MacApp 3.0
TmCT Think C with TCL
TmPT Think Pascal with TCL
After entering a type, clicking the Show button will refresh the list with the set of templates of that type.
The Extract button will write all the templates out as individual text files where each text file name is the resource name.
This program can also open TEXT files into Styled TextEdit windows; it allows arbitrary editing (including full undo support), and saves the style information in a 'styl' resource. It has a Window menu that keeps track of open windows, and that tiles and stacks windows. It has a Font menu and a Style menu that track the font, size and style of the current selection. It has a Clipboard window that shows the contents of the private scrap. As an application, it’s not much; rather, it's an indication of what can be achieved with AppMaker Behaviours with literally a few clicks of the mouse, and a few hundred extra lines of code (the extra lines of code pertained to getting template data out of AppMaker).
About AppMaker Behaviours
AppMaker Behaviours will be available for procedural language programmers, object-oriented programmers, and class library programmers using the following platforms:
• Class libraries: Think C + TCL, Think Pascal + TCL, MPW C++ 3.2 with MacApp 3.0
AppMaker Behaviours will generate object-oriented code with or without a class library; you can experiment with OOP techniques without having to use the TCL or MacApp (or eventually Bedrock).
AppMaker Behaviours extends AppMaker by factoring code so that the user has to write as little glue code as possible. By using a messaging approach, menu commands can be generic, and window functionality is grouped together rather than being scattered throughout an application. In object-oriented code generation, the dispatcher is mostly implicit; polymorphism is used to handle most of the message passing. In procedural code, the messaging is handled by an explicit dispatcher.
The user selects behaviours by name. To add a windows menu to the application (with dynamic window names, stacking and tiling features, etc), the user simply creates a menu called Window. At code generation time, AppMaker Behaviours automatically adds the appropriate code to the application to manage a windows menu. To add a PICT file browser window, the user creates a window named PictWindow.; to have an About dialog instead of an About alert, the user simply creates a dialog named About; and so on.
A partial list of available behaviours includes:
• Smarter File and Edit menus
• Font, Size, Style, Window menus
• Plain or Styled TextEdit window
• PICT file viewer window
• Word Solution Engine word-processor window
• Programmer’s Editor text-editor window
• About dialog
• Printing (including print status and customized dialogs)
This list is by no means comprehensive, as behaviours and features are added constantly.
What makes this superior to a class library?
Currently, there are roughly three categories of programming effort.
The first category, and the one that requires the most effort, is writing an entire program from scratch. This is rarely done, especially by experienced programmers. Typically, it's done only when there is no prior (published) art.
The second category involves the venerable art of programming by “cut and paste”, where parts of a program are inherited from other previously-written programs. This might be from actual code on disk, or code adapted from a book or magazine article. The problems with this, of course, are finding code to copy, and in successfully integrating copied code into a new program. One of the holy grails of software engineering is code re-use.
The third category is where class libraries are used, with the idea being that the class library takes care of the behaviour common to most applications, leaving the programmer free to concentrate on the parts unique to his program. Class libraries make it easier to integrate (usually by forcing you to follow the class library's metaphor), but can involve a very large learning curve. Class libraries also tend to impose a (sometimes large) overhead of space and execution time; this may or may not be inherent in class libraries, but is evident in existing class libraries on the Macintosh.
AppMaker, and especially AppMaker Behaviours, falls somewhere in between the second and third categories. AppMaker helps the re-use of code by packaging it with interface design tools. It also aids in the learning curve with class libraries by generating code that works with class libraries.
AppMaker Behaviours is a step along the way of a new programming category, that of the programmer's assistant. Ideally, one would like to be free to write the new unique code for an application, and have the framework code be melded to the new code automagically. Even when using a class library, one must write lines of glue code to invoke class library procedures, and to do that the class library must often be comprended in toto. The programmer's assistant should help the programmer in working with the environment, whatever the environment might be.
One important feature—program size. AppMaker Behaviours can produce a robust program that's a fraction the size of a TCL or MacApp program, or even a fraction the size of a normal AppMaker-generated program.
Availability?
AppMaker Behaviours is a research project mutating into a product. Currently, the Behaviours templates produce procedural code for Think C 5.0 and MPW C 3.2. Concurrently with the procedural code, but behind in stability, is object-oriented code for Think C 5.0 and MPW C++ 3.2. This object-oriented code is independent of a class library; the Think C code does not use TCL, and the MPW C++ code does not use MacApp.
The first release of AppMaker Behaviours will be procedural C and Pascal (both Think and MPW), and is tentatively scheduled for December 1992. Object-oriented (non-class-library) Behaviours will follow that, with class library Behaviours pending more information about Bedrock scheduling. No pricing has yet been set.
If you are interested in being a beta tester for the procedural AppMaker Behaviours, send an email message describing yourself and your level of programming ability. Obviously, you must already have AppMaker. The first round of beta testing will start in October or November, and will involve procedural Think C templates (Think Pascal might be advanced to the same time-frame if there are enough beta testers for it).
We are looking for a range of programming abilities, so don't feel as if you must be an ace programmer to beta-test AppMaker Behaviours; in fact, we do want some beginning programmers. What we do insist is that beta testers be sincere, and have the time to spend a lot of hours doing the beta testing. AppMaker Behaviours is stable enough that you will be able to write real programs with it, so you should be able to do the beta testing in conjunction with other Macintosh programming.
To be a beta tester, or to get on a mailing list to get future information about AppMaker Behaviours, send an email message describing yourself (don't forget email addresses!) to:
Brian Fitzgerald
CompuServe: 72250,3226
Internet: bfitz@aol.com
America Online: bfitz
BIX: bfitz
AppleLink: D0366
GEnie: HAL.LABS
Beta testers will be selected and notified at least two weeks before the first round of beta testing commences.
Correspondence
If you have your own strong ideas about what the future of programming tools should look like, or if you have specific requests about AppMaker Behaviours you'd like to see, or even if you just want to talk about programming in general, email correspondence is always welcome, at any of the above addresses (listed in decreasing order of preference anding).
